Java technology is both a high-level, object-oriented programming language and a platform. As with most technologies, newer versions of the Java platform are periodically released. Ideally software vendors try to develop applications or tools that require the lowest level of Java as possible to ensure that a broad range of customers can use their products. However, one problem experienced by software vendors who develop applications is that applications developed for an earlier version of Java are not generally compatible with new versions of Java. The following is an example of this problem discussed with respect to a Java Database Connectivity (“JDBC”) driver.
A certain minimum level of Java Runtime Environment (“JRE”) is always required for a specific version of Java Database Connectivity (“JDBC”) specification. For example, the prerequisite level for JDBC 2 is JRE 1.2, for JDBC 3 is JRE 1.4, and for the latest JDBC 4 is JRE 6.0. In order to support a specific version of JDBC specification, a seemingly straightforward solution is to always require a database driver to run with the prerequisite level of Java system. For example, Microsoft's SQL Server 2005 JDBC Driver is JDBC 3 compliant and runs on the JRE 1.4 and later versions. In addition to standard JDBC functionalities, a number of database drivers also include vendor-specific features, most of which do not depend on the underlying level of Java system. Moreover, from the customers' perspective, many of them do not like to move to a new level of Java system too fast for stability reason. Furthermore, vendors who develop applications based on database drivers also prefer a low prerequisite level of Java system for easy adoptability of their products. However, the previous solution forces the minimum level of Java system for the database driver to be the same as that for the highest supported JDBC specification.
Many database driver vendors thus adopt an alternative solution, which spins off a new stream for support of each JDBC specification with a different prerequisite level of Java system. For example, Sybase provides a stream “conn2.jar” for JDBC 2 support on JRE 1.2 and a stream “conn3.jar” for JDBC 3 support on JRE 1.4. Oracle provides a stream “classes12.zip” for JDBC 2 support on JRE 1.2 and a stream “ojdbc14.jar” for JDBC 3 support on JRE 1.4. However, one of the major drawbacks for this solution is that code is duplicated all over the place among separate streams. Besides, each additional stream means additional development, service, and testing effort. This is why some database driver vendors use a third solution, which splits new classes for new JDBC support to avoid dual stream process.
The classes are compiled under different prerequisite levels of Java systems and then bundled together at the end. For example, Cloudscape has a set of major classes for JDBC 3 and another set of major classes for JDBC 4. JDBC 3 specific classes are compiled using JRE 1.4, and JDBC 4 specific classes are compiled using JRE 6.0. At the end, all of these classes are bundled in one Java Archive (JAR) file. However, the JAR file with byte-code compiled under different Java systems is still inadequate and insufficient under certain circumstances. This mixed byte-code solution is not compatible under an IDE, such as Eclipse, because of the multiple Java system build requirement. In addition, it may work for support of one connectivity type with a single inheritance hierarchy, but it does not fit well for support of multiple connectivity types, which most major database vendors have, due to the fact that Java system does not support multiple inheritance hierarchy.
Therefore a need exists to overcome the problems with the prior art as discussed above.